What is the motivation of including this in the "Mender core"?

@mirzak according to https://www.freedesktop.org/software/systemd/man/machine-id.html this value should "stays constant for all subsequent boots". It seems to me a bug that we have different ids depending on which rootfs is active.

Dang. I just realized I didn't push this branch into my fork but rather into the main fork. Oh well. I guess we'll just leave it for now.

@kacf I squashed the two patches together. I've still got the grub-mender stuff here as a patch so I can test. I'll submit separately to that repo and when that is merged I can update this with the new commit hash.

I need this fix for thud; should we include the grub-mender-grub-env fix as a patch there or in an appropriate branch?

I think there is a difference between "subsequent boots" and image update and I do not believe that we are violating any rules here.

The machine-id is something that is generated on first boot, and imo if a user wants to preserve this id across firmware updates they can either provide this id in the data partition or use a state-script to migrate it, or generate it a build time and provide it as a kernel argument. I do not think that we should include this in the Mender core functionality.

There are other "ids" that we are not migrating such as, ssh identity, dbus machine id (which is referred to by systemd docs as well), and probably other things that I am not aware of. And if we are not preserving them all, then I do not think that should treat the "machine-id" any differently.

Well, the dbus uuid is usually a symlink to the systemd machine-id so that one is being handled with this patchset as well. You are correct that we don't do anything with the ssh key but maybe we should? Since Mender is an updater and not an installer, I don't think of the two images as fundamentally different. I certainly would not expect my IDs to change on my laptop when I ran an "apt-get update".

I see Mirza's point, but I think I'm leaning towards the principle of "works out of the box". It's not easy to configure this sort of thing yourself, and Drew's implementation is relatively "soft" in the sense that it does nothing if either the file is missing of you're not using systemd. FWIW, I tried to replace /etc/machine-id with a symlink to /data/machine-id and all hell broke loose, so it's not easy to go that route.

Machine-id is a standard component of systemd, so I think it's reasonable to take it into account if mender-systemd is enabled.

@drewmoseley: I think your patch got messed up somehow. There are several unrelated changes in there now...

@kacf sorry, I forgot to mention that. I had to make some other updates just to get it to build. Of course I have other locally that are required to build in master now that are not submitted; notably the LAYERSERIES_COMPAT stuff. How should we handle this since the current HEAD of master won't build for testing? Is the Jenkins stuff using an older commit hash?

Our master branch is entirely based on the latest stable poky branch, IOW thud (there is a ticket for warrior, not there yet), which was updated just last week, so it's pretty recent. The difference in our thud and master branch ATM is only our own features, plus the fact that master will eventually become warrior, whereas our thud branch will stay as is.

You mentioned that you had a thoroughly tested thud variant. You can probably submit that to meta-mender/master, since it builds with thud.

OK. I force pushed my thud version here. I'll keep the other one locally since there were some minor changes needed to get it to apply but the warrior work may supersede that.

Oh, and I created mendersoftware/grub-mender-grubenv#8. Once that is merged, I can update this to use the new commit hash rather than a local patch.

FWIW, I tried to replace /etc/machine-id with a symlink to /data/machine-id and all hell broke loos

Yeah would assume this to be problem, but there is a somewhat simple solution to make sure /data is mounted before systemd runs.

/sbin/init

#!/bin/sh
mount /dev/mmcblk0p4 /data
exec /lib/systemd/systemd "$@"

I see Mirza's point, but I think I'm leaning towards the principle of "works out of the box"

But has it not worked out of the box so far? I understand that the machine-id might change between updates, but is this a problem as in breaking functionality? I would not expect it to break anything as each update is considered a "first time boot".

I am not gonna oppose strongly against this, just looking to understand

Application code may depend on this. In fact, this came up due to a user application who was using the machine id and it broke their code when it changed.

I'm wondering if we should setup things like ssh keys, wifi creds, etc as persistent when Mender is enabled? Maybe it can be an optional config but I think it would be useful to have since many users need that.

I'm wondering if we should setup things like ssh keys, wifi creds, etc as persistent when Mender is enabled? Maybe it can be an optional config but I think it would be useful to have since many users need that.

This is definitely a gray area, and as we can see there are different opinions. I think I would draw the line at things that change the rootfs. And indeed this PR does not change the rootfs, we only store one value in the bootloader area, and systemd already has the necessary mechanics to pick this up via the kernel cmdline. For SSH keys we would have to write those keys to the filesystem, which is a bit more intrusive, and possibly in direct conflict with other key arrangements.

OTOH I'm not strongly leaning one way or the other either. I can see pros and cons in either direction. @drewmoseley, have you run into the original issue more than once? One option is to just put this in the "wait and give it some time" pile, and see if this is a recurring issue.

I've discussed it with a number of users but in most cases we would handle the changes in their layer. If there were a configurable option in the mender layer it would certainly make it easier for them and more consistent.

For this particular fix, I have a current user who needs this on Thud.

Ok, still only one user though. Mirza's primary concern was adding this to the core functionality, so how about providing this under a MENDER_FEATURE like mender-preserve-machine-id or something like that? This would mean going back to the patch approach that Drew first proposed, instead of adding it directly to grub-mender-grubenv. @mirzak, @drewmoseley, is that an ok solution?

I'm fine with that; plus we can then add things like mender-preserve-ssh-keys and mender-preserve-wifi-credentials which I'm sure users would find useful.

Although, I think using mender-persist-* would probably be more self-explanatory.

👍

This would mean going back to the patch approach that Drew first proposed, instead of adding it directly to grub-mender-grubenv. @mirzak, @drewmoseley, is that an ok solution?

Makes sense to me.

@kacf @mirzak I finally got around to conditionalizing this based on a MENDER_FEATURE. Note that the patch to grub-mender-grubenv is still valid since within the patch it checks if the env variable is set before adding it to the command line. I think we should still consider merging mendersoftware/grub-mender-grubenv#8 so that it works for non-Yocto builds.

What do you think about adding other mender-persist FEATURES? ie mender-persist-wifi-credentials which would modify wpa_supplicant, NetworkManager and connman recipes?

Done, although now I guess we need a commit hash update for grub-mender-grubenv.

Yes, I have arranged the branches correctly, and am testing in #791.